---
title: Depanare
description: Această secțiune explică cum să depanezi Ultracite.
---

Chiar dacă Ultracite își propune să simplifice linting-ul/formatarea, este posibil să întâmpini unele probleme sau să ai întrebări în timpul configurării și utilizării. Iată câteva probleme comune și soluțiile lor:

## “Ultracite isn’t formatting on save in VS Code.”

Verifică de două ori că ai instalat și activat extensia Biome pentru VS Code. Asigură-te că `.vscode/settings.json` conține intrările `"editor.defaultFormatter": "biomejs.biome"` și `"editor.codeActionsOnSave"` așa cum sunt arătate în [Configurare](/setup).

De asemenea, verifică să nu existe o extensie de formatare sau linter în conflict activă (de exemplu, dacă încă ai extensia Prettier sau extensia ESLint active, acestea pot interveni sau pot avea prioritate).

S-ar putea să fie necesar să dezactivezi Format On Save al VS Code dacă alt formatter preia fișierul. Cu setările corecte și extensia Biome, salvarea unui fișier acoperit de Ultracite (js/ts/jsx/tsx/json/css) ar trebui să declanșeze formatarea. Dacă nu se întâmplă, încearcă să rulezi manual comanda "Format Document" și vezi dacă Biome este utilizat sau apare vreun eroare.

## “I installed Ultracite, but VS Code still uses ESLint or Prettier.”

Asigură-te că ai eliminat sau dezactivat vechile tale configurații. De exemplu, dacă ai un fișier `.eslintrc` sau `.prettierrc` în proiect, extensia ESLint a VS Code ar putea fi încă activă și provoca diagnostice duplicate.

Se recomandă să elimini acele configurații (sau cel puțin să dezactivezi extensiile) când treci la Ultracite pentru a evita confuzia. În esență, lasă Ultracite/Biome să preia rolul de singur linter/formatter.

Dacă preferi să păstrezi ESLint dintr-un motiv anume, nu activa „fix on save” pentru ESLint – altfel ambele ar putea încerca să corecteze codul (deși, dacă sunt configurate corect, Biome ar trebui să coincidă cu stilul Prettier pentru a evita conflictele).

În general, migrarea completă la Ultracite înseamnă că nu mai ai nevoie de configurații ESLint / Prettier.

## “Ultracite (Biome) is throwing parse errors for files I don’t want it to check.”

Un exemplu bun este instalarea de componente dintr-o bibliotecă UI precum [`shadcn/ui`](https://ui.shadcn.com/). Deși sunt proiectate pentru a fi modificate, s-ar putea să dorești să păstrezi codul sursă original pentru actualizări. În acest caz, vei dori să dezactivezi linting-ul pentru acele fișiere.

Pentru a face asta, adaugă pattern-uri în `biome.jsonc` pentru a exclude acele fișiere, de ex.

```json title="biome.jsonc"
{
  "files": {
    "includes": [
      "**/*",
      "!components/ui",
      "!lib",
      "!hooks",
    ]
  },
}
```

Implicit, Biome ar trebui să ignore `node_modules`, dar dacă ai deschis manual un fișier din acel director, extensia s-ar putea totuși să încerce să-l lint-eze. În general, ignoră fișierele grele generate sau codul third-party – nu este nevoie să le lint-ezi.

O altă cauză ar putea fi dacă ai sintaxă experimentală într-un fișier pe care Biome nu o poate parsa (de ex., o propunere stage-3 care încă nu este în Biome). În acest caz, fie evită acea sintaxă, fie vezi dacă Biome poate fi configurat (uneori adăugând `"parser.allowSomething": true` în configurație dacă este disponibil).

Verifică tracker-ul de issue-uri al Biome pentru suportul acelei sintaxe.

## “I see double errors for the same issue.”

Acest lucru se poate întâmpla dacă ai mai mulți linteri rulând în paralel (de exemplu, atât ESLint cât și Ultracite). Se poate întâmpla și dacă validatorul TypeScript al VS Code și Biome raportează aceeași eroare TS. Pentru a rezolva, standardizează folosirea unui singur instrument pe tip de verificare.

Dacă folosești Ultracite, dezactivează ceilalți linteri. Pentru erorile de tip TypeScript, serverul TS încorporat al VS Code le va afișa (de ex., valuri roșii pentru probleme de tip) – Biome poate de asemenea afișa probleme de lint bazate pe tipuri. De obicei este în regulă deoarece semnalează aceeași problemă. Dar dacă te deranjează, poți dezactiva validatorul TS al VS Code (`"typescript.validate.enable": false` în setări) și te poți baza pe Biome, sau invers.

În majoritatea configurațiilor, a lăsa ambele active este OK; ele de obicei se completează reciproc (erori de tip vs erori de lint). Doar asigură-te că nu ai doi linteri cu funcționalitate suprapusă activați (cum ar fi ESLint și Biome făcând amândouă linting).

## “Pre-commit hook/CI is failing due to Ultracite.”

Dacă hook-ul pre-commit rulează `ultracite` și eșuează, înseamnă că mai sunt probleme care nu au fost auto-fixate (sau cineva a ocolit rularea). Cea mai bună soluție este să rulezi `npx ultracite` local și să inspectezi output-ul. Fie va rezolva automat (în caz în care doar stage-uiești schimbările și comiți din nou), fie va raporta erori care necesită corecție manuală.

Rezolvă acele probleme, apoi comite. Dacă CI eșuează pe `ultracite --check`, fă la fel: rulează-l local cu `--check` ca să vezi ce a găsit, sau rulează fără `--check` pentru a auto-fixa și comite rezultatele. Pe scurt, tratează eșecurile Ultracite ca pe teste care pică – ceva de corectat în cod.

## “I get an error about `strictNullChecks` or type issues after enabling Ultracite.”

Ultracite presupune un nivel ridicat de strictete TypeScript. Dacă nu ai activat `strictNullChecks` (sau `strict` complet), s-ar putea să primești multe avertismente legate de TypeScript (de exemplu, plângându-se despre utilizarea posibilă a valorilor nedefinite pe care TS nu le prinde din cauza setărilor relaxate).

Soluția este să activezi acele flaguri stricte în `tsconfig` așa cum se recomandă. Dacă dintr-un motiv anume nu poți (din motive legate de cod legacy), s-ar putea să fii nevoit să dezactivezi anumite reguli în Ultracite care presupun strictness. Dar este foarte recomandat să faci trecerea la modul strict TS – va îmbunătăți calitatea codului și este în concordanță cu filosofia Ultracite.

## “Ultracite is too strict for our team (too many rules) – can I tone it down?”

Da. Deși valoarea Ultracite este în a fi strict, ești liber să suprascrii reguli. Dacă dezvoltatorii sunt copleșiți de avertismente, identifică regulile care cauzează fricțiune. Poate este o preferință stilistică sau ceva care nu are sens pentru contextul vostru. Poți seta acele reguli la `warn` sau `off` în config.

De exemplu, dacă găsești regulile de accesibilitate prea zgomotoase pentru un tool intern, ai putea dezactiva unele dintre ele. Sau dacă nu ești de acord cu un stil de cod impus, îl poți ajusta (deși dezacordurile de stil sunt exact ceea ce Ultracite încearcă să elimine).

Cheia este comunicarea cu echipa – poate educă de ce o regulă există înainte de a o dezactiva; dacă tot nu este dorită, personalizează configurația. Ultracite nu este o cutie neagră – ai control total prin `biome.jsonc`.

Consultă secțiunea [configurare](/configuration) pentru mai multe informații despre cum să suprascrii regulile.

## “Are there known limitations or bugs with Ultracite I should be aware of?”

Ultracite (în special Biome) nu acoperă tot ce fac ESLint + Prettier + Stylelint, mai ales dacă folosești anumite plugin-uri. De exemplu, Stylelint avea reguli exhaustive pentru CSS; Biome oferă în prezent formatare pentru CSS și lint de bază, dar nu întreg setul de reguli Stylelint.

Dacă proiectul tău se bazează pe anumite verificări Stylelint (cum ar fi ordonarea proprietăților sau numiri specifice în CSS), reține că Ultracite nu le impune. Poți incorpora Stylelint separat dacă este absolut necesar, sau poți aștepta ca Biome să introducă mai mult linting pentru CSS în viitor.

---

Dacă întâmpini o problemă care nu este acoperită aici, ia în considerare verificarea paginii de issue-uri a Ultracite pe GitHub sau documentația Biome. S-ar putea să existe o soluție sau un workaround disponibil. Comunitatea este în creștere, deci suportul se îmbunătățește în timp.